RTCA DO-178C 항공기 시스템 및 장비 인증을 위한 소프트웨어 고려사항

1. 서론: 항공 우주 소프트웨어 인증의 패러다임과 진화

1.1 표준의 정의 및 목적

현대 항공 산업에서 소프트웨어는 단순한 보조 장치를 넘어 비행 제어, 항법, 엔진 관리 등 항공기의 핵심 기능을 담당하는 중추적인 요소로 자리 잡았다. 이러한 소프트웨어의 오작동은 치명적인 인명 피해와 자산 손실로 이어질 수 있기에, 극도로 엄격한 안전성 검증이 요구된다. RTCA DO-178C(유럽 표준명 EUROCAE ED-12C)인 “Software Considerations in Airborne Systems and Equipment Certification“은 이러한 안전성 확보를 위해 전 세계 항공 규제 당국이 채택한 사실상의 국제 표준이다.1

이 문서는 특정 코딩 스타일이나 개발 방법론을 강제하는 규정집이 아니다. 대신, 소프트웨어 생명주기(Software Life Cycle) 동안 달성해야 할 명확한 ’목표(Objectives)’를 제시하고, 이를 충족했음을 입증하는 ’증거(Evidence)’를 요구하는 객관성 기반(Objective-based) 접근 방식을 취한다.1 미국 연방항공청(FAA), 유럽 항공안전청(EASA), 중국 민용항공국(CAAC) 등 주요 인증 당국은 상용 항공기 시스템의 감항성(Airworthiness)을 승인하는 수단으로 이 표준을 사용한다.1

1.2 역사적 배경 및 DO-178B로부터의 진화

DO-178의 역사는 항공 소프트웨어 기술의 발전과 궤를 같이한다. 1980년대 초반 DO-178(1981)과 DO-178A(1985)는 소프트웨어의 중요성이 부각되기 시작하던 시기에 만들어져 문서화와 테스트에 초점을 맞춘 규범적(Prescriptive) 성격이 강했다.3 1992년 발표된 DO-178B는 프로세스 중심의 접근 방식을 도입하며 지난 20년간 항공 소프트웨어 인증의 바이블로 군림해왔다.

그러나 시간이 흐르며 모델 기반 개발(Model-Based Development), 객체 지향 프로그래밍(OOP), 형식 기법(Formal Methods) 등 새로운 소프트웨어 엔지니어링 기술이 등장했고, 기존 DO-178B로는 이를 명확하게 수용하기 어려운 한계에 봉착했다. 이에 따라 RTCA 특별 위원회 SC-205와 EUROCAE 워킹 그룹 WG-71은 DO-178B의 핵심 철학을 유지하면서도 최신 기술을 반영하고, 기존 문서의 모호성을 개선한 DO-178C를 2011년에 발표하였다.1 DO-178C는 단순한 개정판이 아니라, 현대적 개발 환경을 포괄하는 새로운 생태계를 구축한 것으로 평가받는다.

1.3 민간 표준의 국방 분야 확대

전통적으로 군용 항공기는 각국의 국방 규격을 따랐으나, 최근에는 민간 규격인 DO-178C를 채택하는 추세가 강화되고 있다. 이는 민간 항공 규정의 성숙도와 일관성이 높게 평가받고 있기 때문이며, 전 세계적으로 군용 항공전자 시스템의 감항성을 입증하는 데 있어 DO-178C가 “사실상의 표준(De facto standard)“으로 자리 잡고 있다.1 미군 및 여러 국방 기관은 임무 성공(Mission Success)과 안전(Safety)을 보장하기 위해 군용 프로젝트에도 DO-178C 준수를 요구하고 있으며, 이는 상용 기성품(COTS) 활용 확대와 더불어 국방 소프트웨어 획득 비용 절감 및 신뢰성 향상에 기여하고 있다.4

2. 안전성 평가와 설계 보증 레벨 (Design Assurance Level)

2.1 시스템 안전성 평가와의 연계

DO-178C는 독립적으로 존재하는 것이 아니라, 시스템 레벨의 안전성 평가 프로세스와 긴밀하게 연결되어 있다. SAE ARP 4754A(시스템 개발 보증) 및 ARP 4761(안전성 평가 프로세스)에 따라 수행된 기능적 위험 평가(FHA: Functional Hazard Assessment)와 예비 시스템 안전성 평가(PSSA)의 결과는 소프트웨어의 설계 보증 레벨(DAL)을 결정하는 입력이 된다.5 즉, 소프트웨어의 중요도는 그 소프트웨어가 오작동했을 때 시스템과 항공기에 미치는 영향의 심각도(Severity)에 의해 결정된다.

2.2 실패 조건에 따른 DAL 분류 및 목표

DO-178C는 소프트웨어의 실패가 초래할 수 있는 결과에 따라 5단계의 DAL(Level A ~ Level E)을 정의한다. 레벨이 높을수록(A에 가까울수록) 준수해야 할 목표의 수가 많아지고, 검증의 엄격함이 증가한다.5

레벨	실패 조건 (Failure Condition)	정의 및 영향	목표 수	독립성 필요
Level A	재앙적 (Catastrophic)	항공기의 손실 및 탑승객 전원의 사망을 초래할 수 있는 실패.	71	30
Level B	위험함 (Hazardous)	안전 여유의 심각한 감소, 승무원의 업무 과부하, 소수의 탑승객 사망 가능성.	69	18
Level C	주요함 (Major)	안전 여유의 상당한 감소, 승무원 업무량 증가, 탑승객의 부상 가능성.	62	5
Level D	경미함 (Minor)	안전 여유의 경미한 감소, 탑승객의 불편함 초래.	26	2
Level E	영향 없음 (No Safety Effect)	항공기 운항 능력이나 조종사의 업무 부하에 영향 없음.	0	0

표 1: DO-178C 설계 보증 레벨(DAL)에 따른 분류 및 목표 요약 1

2.3 독립성(Independence)의 원칙

상위 레벨(Level A, B)에서는 단순한 검증을 넘어 ’독립성’이 요구된다. 이는 검증 활동을 수행하는 인력이 해당 소프트웨어 아티팩트(요구사항, 코드 등)를 개발한 인력과 달라야 함을 의미한다.7 예를 들어, Level A 소프트웨어의 경우 소스 코드를 작성한 엔지니어는 자신의 코드를 검증하는 테스트 케이스를 작성하거나 커버리지 분석을 수행할 수 없다. 이 원칙은 개발자의 잠재적 편향(Bias)을 제거하고 객관적인 시각에서 오류를 검출하기 위한 핵심 안전장치이다. Level C 이하에서는 이러한 독립성 요구가 대폭 완화되는데, 이는 리스크 기반 접근법에 따라 제한된 자원을 가장 치명적인 부분에 집중하기 위함이다.9

3. 소프트웨어 생명주기 프로세스: 계획 및 개발

DO-178C의 프로세스는 크게 계획(Planning), 개발(Development), 통합(Integral) 프로세스로 분류된다. 이들은 순차적으로만 진행되는 것이 아니라 상호 보완적이고 반복적으로 수행된다.1

3.1 소프트웨어 계획 프로세스 (Software Planning Process)

프로젝트 초기에 수립되는 계획 문서는 인증 당국과의 합의를 형성하는 기초가 된다. 계획 단계의 부실함은 프로젝트 후반부의 재작업과 인증 실패로 이어질 수 있다.

3.1.1 주요 계획 문서

DO-178C 준수를 위해 반드시 작성되어야 할 5가지 핵심 계획서는 다음과 같다.3

인증 측면 계획서 (PSAC: Plan for Software Aspects of Certification): 인증 당국에 제출되는 주된 문서로, 시스템 개요, 소프트웨어 레벨, 준수 방법(Means of Compliance), 인증 일정 등을 기술한다. PSAC는 인증 당국이 개발사가 제안한 생명주기가 적절한지 판단하는 근거가 된다.13 특히 이전에 개발된 소프트웨어(PDS)나 상용 기성품(COTS) 사용 계획, 도구 자격 부여 계획 등이 포함되어야 한다.
소프트웨어 개발 계획서 (SDP: Software Development Plan): 소프트웨어 요구사항 분석, 설계, 코딩, 통합 과정에서 따를 구체적인 방법론과 생명주기 모델을 정의한다.3
소프트웨어 검증 계획서 (SVP: Software Verification Plan): 리뷰, 분석, 테스트를 포함한 검증 전략을 수립한다. 테스트 환경, 도구 사용 계획, 그리고 각 DAL에 따른 구조적 커버리지 달성 방안을 명시한다.2
소프트웨어 형상 관리 계획서 (SCMP: Software Configuration Management Plan): 변경 제어, 베이스라인 설정, 버전 관리, 데이터 보존 및 아카이빙 절차를 상세히 기술한다.3
소프트웨어 품질 보증 계획서 (SQAP: Software Quality Assurance Plan): QA 조직의 권한, 독립성, 감사(Audit) 일정 및 범위를 정의하여 프로세스 준수 여부를 감시하는 방법을 기술한다.12

이 외에도 소프트웨어 요구사항 표준(SRS), 설계 표준(SDS), 코딩 표준(SCS)이 정의되어야 하며, 이는 개발 결과물의 일관성과 품질을 보장하는 기준이 된다.4

3.2 소프트웨어 개발 프로세스 (Software Development Processes)

개발 프로세스는 요구사항 정의부터 코드 생성까지의 엔지니어링 활동을 포함한다.

소프트웨어 요구사항 프로세스: 시스템 요구사항을 상위 레벨 요구사항(HLR: High-Level Requirements)으로 분해하고 구체화한다. 이 과정에서 시스템 안전성 평가로부터 도출된 안전 관련 요구사항과 파생 요구사항(Derived Requirements)을 식별하는 것이 중요하다. 파생 요구사항은 시스템 요구사항에는 명시되지 않았으나 소프트웨어 설계 특성상 필요한 요구사항으로, 반드시 시스템 안전성 평가 프로세스로 피드백되어야 한다.10
소프트웨어 설계 프로세스: HLR을 기반으로 소프트웨어 아키텍처를 수립하고 하위 레벨 요구사항(LLR: Low-Level Requirements)을 정의한다. 데이터 흐름과 제어 흐름이 명확히 정의되어야 하며, 파티셔닝(Partitioning) 전략을 통해 서로 다른 DAL을 가진 소프트웨어 간의 간섭을 방지해야 한다.10
소프트웨어 코딩 프로세스: LLR을 소스 코드로 구현한다. 코딩은 사전에 정의된 코딩 표준을 엄격히 준수해야 하며, 복잡도를 제한하여 검증 용이성을 확보해야 한다. 자동 코드 생성 도구를 사용할 경우, 해당 도구의 자격 부여(Qualification)가 중요한 고려사항이 된다.2
통합 프로세스: 컴파일된 객체 코드를 타겟 하드웨어에 로드하고, 하드웨어와 소프트웨어, 그리고 소프트웨어 컴포넌트 간의 상호작용을 통합한다. DO-178C에서는 파라미터 데이터 항목(PDI) 파일의 로딩 및 통합 또한 이 단계에서 엄격히 관리될 것을 요구한다.15

4. 통합 프로세스 I: 소프트웨어 검증 (Verification)

검증은 DO-178C 생명주기에서 가장 많은 자원이 투입되는 활동으로, 단순히 버그를 찾는 테스트를 넘어 소프트웨어의 완전성과 정확성을 입증하는 포괄적인 활동이다.

4.1 검증의 세 가지 유형: 리뷰, 분석, 테스트

검증 활동은 크게 세 가지 범주로 나뉜다.

리뷰 (Reviews): 요구사항, 설계, 코드, 테스트 케이스 등의 산출물을 사람이 검토하는 정적 검증 활동이다. 체크리스트를 활용하여 표준 준수 여부, 정확성, 일관성을 확인한다.18
분석 (Analyses): 테스트만으로는 확인하기 어려운 속성들, 예를 들어 최악 실행 시간(WCET), 스택 사용량, 데이터 결합 및 제어 결합(Data Coupling and Control Coupling), 파티셔닝 무결성 등을 수학적 또는 논리적으로 분석한다.3
테스트 (Tests): 실행 가능한 코드를 실제로 구동하여 동작을 확인한다.

4.2 요구사항 기반 테스트 (Requirements-Based Testing)

DO-178C의 모든 테스트는 소스 코드가 아닌 요구사항에서 도출되어야 한다. 이는 “코드가 무엇을 하는가“가 아니라 “코드가 요구사항대로 동작하는가“를 검증하기 위함이다.19

정상 범위 테스트 (Normal Range Testing): 입력값이 정상 범위 내에 있을 때의 동작을 확인한다.
견고성 테스트 (Robustness Testing): 입력값이 비정상적이거나 경계값일 때, 또는 시스템 상태가 예외적일 때 소프트웨어가 안전하게 반응하는지를 확인한다. 이는 시스템 실패를 방지하는 핵심 활동이다.20

4.3 구조적 커버리지 분석 (Structural Coverage Analysis

요구사항 기반 테스트가 수행된 후, 그 테스트가 소스 코드의 구조를 얼마나 커버했는지를 측정한다. 이는 “요구사항에 없는 코드(Dead Code)“를 찾아내거나, 테스트가 부족한 부분을 식별하기 위함이다. DAL에 따라 요구되는 커버리지 수준은 다음과 같다.7

커버리지 유형	설명	적용 DAL
구문 커버리지 (Statement Coverage)	모든 코드 구문이 최소 한 번 이상 실행되어야 함.	Level A, B, C
결정 커버리지 (Decision Coverage)	모든 분기점(if, while 등)이 True와 False 결과를 최소 한 번씩 가져야 함.	Level A, B
MC/DC (Modified Condition/Decision Coverage)	복합 조건문 내의 각 개별 조건이 전체 결과에 독립적으로 영향을 미침을 입증해야 함.	Level A

특히 Level A에 적용되는 MC/DC는 DO-178C의 가장 엄격한 요구사항 중 하나이다. 이는 복잡한 논리 회로 내에서 특정 조건의 오류가 마스킹되어 발견되지 않는 현상을 방지하기 위해 고안되었다. MC/DC 달성을 위해서는 고도의 테스트 설계 능력과 독립적인 검증이 필수적이다.7

5. 통합 프로세스 II: 추적성, 형상 관리, 품질 보증

5.1 양방향 추적성 (Bidirectional Traceability)

추적성은 DO-178C 인증의 중추 신경망과 같다. 모든 엔지니어링 산출물은 상호 연결되어야 하며, 이는 두 가지 방향으로 유지된다.19

Top-down (상위에서 하위로): 시스템 요구사항 $\rightarrow$ HLR $\rightarrow$ LLR $\rightarrow$ 소스 코드 $\rightarrow$ 실행 파일. 이는 모든 상위 요구사항이 하위 단계에서 누락 없이 구현되었음을 보장한다.
Bottom-up (하위에서 상위로): 소스 코드 $\rightarrow$ LLR $\rightarrow$ HLR $\rightarrow$ 시스템 요구사항. 이는 소스 코드의 모든 라인이 상위 요구사항에 근거하고 있음을 증명한다. 이를 통해 추적되지 않는 “죽은 코드(Dead Code)“나 “의도하지 않은 기능(Unintended Functionality)“을 식별하고 제거할 수 있다.8

또한, 테스트 케이스와 검증 결과 또한 요구사항 및 코드와 연결되어야 하며, 변경 발생 시 영향 분석(Change Impact Analysis)의 기초 데이터로 활용된다.20

5.2 소프트웨어 형상 관리 (SCM)

SCM은 소프트웨어의 “변경“을 통제하고 “재현성“을 보장한다. 단순히 소스 코드의 버전 관리뿐만 아니라, 요구사항 문서, 설계 문서, 테스트 절차, 도구 설정, 파라미터 데이터 항목(PDI) 등 생명주기 전반의 모든 데이터 항목(Data Items)을 관리 대상(Configuration Items)으로 식별한다.23

베이스라인 (Baseline): 특정 시점의 형상 항목들의 집합을 동결하여 기준선을 수립한다.
문제 보고 및 변경 제어 (Problem Reporting & Change Control): 결함이 발견되면 문제 보고서를 작성하고, 변경 제어 위원회(CCB)의 승인을 거쳐 수정이 이루어져야 한다.
아카이브 및 복구: 인증 후에도 소프트웨어를 동일하게 재생성할 수 있도록 모든 환경과 데이터를 보존해야 한다.15

5.3 소프트웨어 품질 보증 (SQA)

SQA는 독립적인 감시자 역할을 수행한다. SQA 활동은 제품 자체의 품질보다는, 제품을 만드는 프로세스의 품질에 초점을 맞춘다. SQA 담당자는 개발 및 검증 팀이 승인된 계획서(Plan)와 표준(Standard)을 준수하고 있는지 주기적인 감사(Audit)를 통해 확인한다.18 또한, 주요 마일스톤(SOI) 이전에 내부 전환 기준(Transition Criteria)이 충족되었는지 확인하고, 최종적으로 소프트웨어 적합성 검토(Software Conformity Review)를 수행하여 인증 준비 상태를 보증한다.24

6. 기술 보충 문서와 현대적 기법의 적용

DO-178C의 가장 큰 혁신은 핵심 문서(Core Document)를 범용적으로 유지하면서, 급변하는 기술 트렌드를 반영하기 위해 보충 문서(Supplements) 체계를 도입했다는 점이다.

6.1 DO-330: 소프트웨어 도구 자격 부여 (Tool Qualification)

과거 DO-178B에서는 도구 자격 부여 기준이 다소 모호했으나, DO-330은 이를 체계화하여 독립적인 표준으로 정립했다. 도구는 그 역할과 오류 가능성에 따라 3가지 기준(Criteria)으로 분류된다.17

Criteria 1: 도구의 출력이 비행 소프트웨어의 일부가 되며, 도구의 오류가 코드에 오류를 삽입할 수 있는 경우 (예: 자동 코드 생성기).
Criteria 2: 도구가 검증을 자동화하며, 도구의 오류로 인해 코드의 결함을 놓칠 수 있고, 그 결과 다른 검증 절차를 생략하거나 축소하는 경우.
Criteria 3: 도구가 검증을 자동화하지만, 도구의 실패가 단지 오류를 검출하지 못하는 것에 그치는 경우 (예: 테스트 러너).

이 기준과 소프트웨어의 DAL을 조합하여 도구 자격 레벨(TQL 1 ~ TQL 5)이 결정된다.

소프트웨어 DAL	Criteria 1	Criteria 2	Criteria 3
A	TQL-1	TQL-4	TQL-5
B	TQL-2	TQL-4	TQL-5
C	TQL-3	TQL-5	TQL-5
D	TQL-4	TQL-5	TQL-5

표 2: DO-330 도구 자격 레벨(TQL) 결정 매트릭스 25

TQL-1은 비행 소프트웨어 개발에 준하는 엄격한 검증을 도구 자체에 요구하는 반면, TQL-5는 기본적인 운영 요구사항 확인 수준에 그친다. 이는 자동 코드 생성 도구(Criteria 1)가 단순 검증 도구(Criteria 3)보다 훨씬 높은 신뢰성을 입증해야 함을 의미한다.

6.2 DO-331: 모델 기반 개발 (MBD)

DO-331은 텍스트 기반 요구사항 대신 모델(Simulink, SCADE 등)을 사용하는 개발 방식을 다룬다. 모델은 ’사양 모델(Specification Model)’과 ’설계 모델(Design Model)’로 구분된다. 설계 모델에서 코드가 자동 생성될 경우, 해당 모델은 LLR 역할을 수행한다.27

DO-331의 핵심 이점은 시뮬레이션을 통한 조기 검증이다. 하지만 모델 커버리지(Model Coverage)가 코드의 구조적 커버리지를 완전히 대체할 수는 없으며, 자동 생성된 코드에 대한 검증 책임은 여전히 존재한다. 특히 모델에서 코드로의 변환 과정에서 의도치 않은 기능이 삽입되지 않음을 보증해야 한다.29

6.3 DO-332: 객체 지향 기술 (OOT) 및 DO-333: 형식 기법

DO-332: 객체 지향 언어의 상속, 다형성, 동적 바인딩 등은 코드의 재사용성을 높이지만 결정론적(Deterministic) 실행을 방해할 수 있다. DO-332는 리스코프 치환 원칙(Liskov Substitution Principle) 준수 확인, 로컬 타입 일관성 검증 등을 통해 OOT의 안전성을 확보하도록 요구한다.31
DO-333: 수학적 논리를 사용하여 소프트웨어의 무결성을 증명하는 형식 기법(Formal Methods)에 대한 지침이다. 이는 복잡한 알고리즘이나 동시성 제어 등을 검증할 때 테스트를 보완하거나 대체하는 강력한 수단이 될 수 있다.32

7. 인증 데이터 항목 및 연락 프로세스

7.1 주요 인증 제출물 (Deliverables)

인증 당국에 제출해야 하는 최소 데이터 항목은 다음과 같다.33

PSAC (Plan for Software Aspects of Certification): 인증 계획서.
SAS (Software Accomplishment Summary): 프로젝트 종료 시 작성하는 인증 요약서. 계획 대비 수행 실적, 변경 사항, 발견된 문제 및 해결 현황 등을 종합적으로 기술한다. 이는 “소프트웨어가 감항 요구사항을 충족함“을 선언하는 최종 문서이다.6
SCI (Software Configuration Index): 소프트웨어 제품의 구성을 정의한다. 소스 코드, 오브젝트 코드, 컴파일러/링커 버전 및 옵션, PDI, 라이브러리 등을 포함하여 소프트웨어를 완벽하게 재생성(Regenerate)할 수 있는 정보를 담는다.34

이 외에도 SRS, SDD, 소스 코드, 검증 결과(SVR), 추적성 매트릭스 등은 제출하지 않더라도 감사를 위해 내부적으로 엄격하게 관리되어야 한다.

7.2 인증 당국 참여 단계 (Stage of Involvement, SOI)

인증 당국은 4단계의 SOI 감사를 통해 프로젝트를 모니터링한다.35

SOI #1 (계획 검토): PSAC 및 계획서, 표준의 적절성 검토.
SOI #2 (개발 검토): 요구사항, 설계, 코딩 프로세스 및 추적성 검토.
SOI #3 (검증 검토): 테스트 절차, 결과, 커버리지 분석 등 검증 활동의 완전성 검토.
SOI #4 (최종 인증 검토): SAS, SCI 검토 및 최종 승인 여부 결정.

각 단계는 게이트(Gate) 역할을 하며, 이전 단계의 지적 사항이 해결되지 않으면 다음 단계로 진행할 수 없다.

8. DO-178B와 DO-178C의 비교 분석

DO-178C는 DO-178B의 기본 구조를 유지하면서도 명확성과 기술 수용성을 대폭 개선했다.

구분	DO-178B (1992)	DO-178C (2011)	의미 및 영향
접근 방식	프로세스 중심	목표(Objective) 및 데이터 중심	유연성 증대, 결과물의 품질 강조
도구 자격	단순 분류 (개발/검증)	5단계 TQL (DO-330)	도구 신뢰성 평가의 체계화 및 엄격화
신기술 수용	명시적 지침 부재	보충 문서 (DO-331, 332, 333)	MBD, OOT 등 현대 기술의 공식적 인증 경로 확보
모호성 제거	일부 목표가 암묵적임	“숨겨진 목표” 명시화	해석의 차이 감소, 일관된 적용 가능
PDI 관리	명시적 언급 부족	PDI에 대한 명확한 검증 요구	설정 데이터 파일 등의 안전성 관리 강화

표 3: DO-178B와 DO-178C의 주요 차이점 비교 3

특히 DO-178C는 DO-178B에서 문맥상으로만 유추해야 했던 “숨겨진 목표(Hidden Objectives)“들을 Annex A 테이블에 명시적인 목표로 추가함으로써 인증 기준의 투명성을 높였다. 예를 들어, DO-178B 섹션 6.4.4.2b에 암시되어 있던 “소스 코드에 추적되지 않는 추가 코드(Additional Code)의 검증“이 DO-178C에서는 Table A-7의 Objective 9로 명확히 신설되었다.8

9. 결론

RTCA DO-178C는 항공 소프트웨어의 안전성을 보장하기 위한 전 세계적인 합의이자 기준이다. 이 표준은 개발자에게 부담스러운 규제로 다가올 수 있지만, 본질적으로는 **결정론적 소프트웨어(Deterministic Software)**를 만들기 위한 체계적인 공학적 가이드라인이다. 요구사항부터 코드, 테스트에 이르는 완벽한 추적성(Traceability) 확보, 독립적인 검증(Independent Verification), 그리고 엄격한 **형상 관리(Configuration Management)**는 예측 불가능한 오류를 제거하고 시스템의 무결성을 보장하는 핵심 기제이다.

현대 항공 산업에서 DO-178C의 적용 범위는 민간 항공기를 넘어 군용기, 드론(UAV), 도심 항공 모빌리티(UAM)로 확장되고 있다. 또한, DO-330, DO-331과 같은 보충 문서의 도입은 자동화와 모델 기반 설계를 통한 개발 효율성 증대라는 새로운 기회를 제공한다. 따라서 항공 소프트웨어 개발 조직은 DO-178C를 단순한 문서 작업이 아닌, 고품질의 안전 필수(Safety-Critical) 시스템을 구축하기 위한 필수적인 역량으로 내재화해야 할 것이다. 성공적인 DO-178C 인증은 철저한 초기 계획, 숙련된 엔지니어링, 그리고 규정 준수를 입증할 수 있는 투명한 프로세스 관리에 달려 있다.

10. 참고 자료

What is DO-178C? - Ansys, https://www.ansys.com/simulation-topics/what-is-do-178c
What Is DO-178C? - Wind River Systems, https://www.windriver.com/solutions/learning/do-178c
DO-178C Guidance: Introduction to RTCA DO-178 certification | Rapita Systems, https://www.rapitasystems.com/do178
DO-178C Intro, Compliance: Free Tools/ Papers / Resources Copy - AFuzion, https://afuzion.com/do-178-introduction-copy/
I’m so confused by DO-178 and determing Development Assurance Levels - Reddit, https://www.reddit.com/r/AerospaceEngineering/comments/1k4l2o2/im_so_confused_by_do178_and_determing_development/
DO-178C Certification - Your Complete Verification Journey - LDRA, https://ldra.com/do-178/
DO-178C testing | Rapita Systems, https://www.rapitasystems.com/do178c-testing
DO-178C - Wikipedia, https://en.wikipedia.org/wiki/DO-178C
DO-178C Certification Explained | ConsuNova, Inc., https://consunova.com/do-178c/certification-unpacked-a-practical-guide-to-do-178c-certification-explained/
What Is RTCA DO-178C? Overview & Compliance in Aerospace - Parasoft, https://www.parasoft.com/learning-center/do-178c/what-is/
Best DO-178C Compliance Tools, Checklists & Templates - Visure Solutions, https://visuresolutions.com/aerospace-and-defense/do-178c-checklists-and-tools/
DO-178C Pre-Project Documents: Foundation for Certifiable Airborne Software - Real Time Consulting, https://real-time-consulting.com/wp-content/uploads/2025/04/DO-178-PreProject-Docs.pdf
DO-178C PSAC - TheCloudStrap, https://thecloudstrap.com/do-178c-psac/
PLAN FOR SOFTWARE ASPECTS OF CERTIFICATION (PSAC) Number: DI-SESS-82336 Approval Date - ASSIST-QuickSearch Basic Search, https://quicksearch.dla.mil/WMX/Default.aspx?token=5771486
DO-178B/C Differences Tool, https://www.faa.gov/sites/faa.gov/files/aircraft/air_cert/design_approvals/air_software/differences_tool.pdf
1. Compliance with DO-178C/ED-12C Guidance: Analysis - learn.adacore.com, https://learn.adacore.com/booklets/adacore-technologies-for-airborne-software/chapters/analysis.html
DO-178C SOFTWARE COMPLIANCE FOR AEROSPACE & DEFENSE - Parasoft, https://alm.parasoft.com/hubfs/ebook-DO-178C-Software-Compliance-Aerospace-Defense.pdf
A Fresh Take on DO-178C Software Reviews | The AdaCore Blog, https://blog.adacore.com/a-fresh-take-on-do-178c-software-reviews
DO-178C: A Discipline on the Provability of Reliability in Airborne Software | by Umut Akbulut | Sep, 2025 | Medium, https://medium.com/@umutt.akbulut/do-178c-a-discipline-on-the-provability-of-reliability-in-airborne-software-9d2f3afbf83b
DO-178C - Software Considerations in Airborne Systems and Equipment Certification, https://quality.arc42.org/standards/do-178c
Complete Verification and Validation for DO-178C - Vector, https://cdn.vector.com/cms/content/know-how/aerospace/Documents/Complete_Verification_and_Validation_for_DO-178C.pdf
Differences and Challenges between DO-178B and DO-178C - Visure Solutions, https://visuresolutions.com/aerospace-and-defense/do-178b-vs-do-178c/
DO-178C Explained | ConsuNova, Inc., https://consunova.com/do-178c-explained/
DO-178C Templates and Checklists - Airworthiness Certification Services, https://airworthinesscert.com/do-254-do-178c-templates-checklists/do-178c-templates-and-checklists/
RTCA DO-330/EUROCAE ED-215 | Rapita Systems, https://www.rapitasystems.com/do-330
DO-330 Introduction – Tool Qualification - AFuzion, https://afuzion.com/do-330-introduction-tool-qualification/
DO-331/ED-216 Model-Based Development and Verification Supplement: When, where, and how it applies - LDRA, https://ldra.com/do-331/
DO-331 Model Based Development and Verification Supplement to DO- 178C and DO-278A - A-P-T Research, Inc., https://www.apt-research.com/wp-content/uploads/2017/05/MBSESSS_DO-331_Alford_Hendrix.pdf
DO-331: Model-Based Development and Verification Supplement to DO-178C and DO-278A - Visure Solutions, https://visuresolutions.com/aerospace-and-defense/do-331/
RTCA DO 331 Model-Based Development and Verification in aerospace - Heicon Ulm, https://heicon-ulm.de/en/rtca-do331-model-based-development-and-verification-in-aerospace/
DO-332: Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A - Visure Solutions, https://visuresolutions.com/aerospace-and-defense/do-332/
DO-332/ED-217 Object-Oriented Technology and Related Techniques Supplement: When, where, and how it applies - LDRA, https://ldra.com/do-332/
Understanding DO-178C Certification Artifacts and Software Life Cycle Data Items for Various DALs - eInfochips, https://www.einfochips.com/blog/understanding-do-178c-certification-artifacts-and-software-life-cycle-data-items-for-various-dals/
Key Concepts and Terminology in DO-178C: A Comprehensive Guide - TheCloudStrap, https://thecloudstrap.com/key-concepts-and-terminology-in-do-178c/
DO-178C - Stage of Involvement 4 | Rapita Systems, https://www.rapitasystems.com/blog/do-178c-SOI-certification-stage-involvement-4
Introduction to DO-178C | Rapita Systems, https://www.rapitasystems.com/blog/introduction-do-178c
DO-178B and DO-178C Differences - PATMOS Engineering Services, Inc., https://patmos-eng.com/do-254-training-do-178c-training/178b-178c-differences/